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Zoned  Analog  Personal  Teleconferencing 

(ZAPT) 

Josefrib  D.  Ibudi^ 

use  /bifoniiati<Mi  Sdenoes  Institute 
toudi@isLedu 


ABSTRACT:  ZAPT  is  a  deskUm  multiparty  audioAfideo  teleconferencing 
system  at  ARRk,  based  on  Bmcote*s  Touring  Machine.  ZAPT  supports 
one  muldparty  call  (up  to  4  parties),  and  any  number  of  point-to-point 
calls,  wM  analog  multimedia.  ZAPT  supports  auUmutied  remote 
operation  and  conference  '‘Join”  requests.  ZAPT  provides  interoffice 
conferencing  at  ARPA,  and  manual  cross-connect  to  Internet  lETF-style 
conferencing  toots. 

1.0  Introduction 

This  is  a  rq>oit  on  the  Zoned  Analog  Personal  TBeconfeiencing  G^APT)  project,  to  port 
BeHcote’s  Iboring  Machine  (the  TbO  smiog  video  tdeconferencing  system  to  die  NeXT  Oibe 
computers  at  ARPA.  ZAPT  was  a  one-year  ^ort,  begun  in  mid-June  1992.  ZAPT  has  been  oper¬ 
ational  since  February  1993,  with  enhjuioements  concluded  in  April  1993.  The  prim^  goal  was 
to  provide  desktop  teleconfeffNidng  at  ARPA  in  minimal  time,  using  AREA’S  masting  miviron- 
ment  ZAPT  uses  Bellcore’s  Tbuting  Machine  with  extensions,  including  passive  bridging,  Bmlt 
management,  a  NeXT-style  user  control  interface,  and  automated  clients.  2^APT  provit^  interof¬ 
fice  d^ktop  video  teleconferencing,  and  manual  cross-coupling  to  existing  Internet  teleconfermic- 
ing.  The  crossbar  control  intetfiioe  and  bridging  extensions  were  shared  with  the  research 
community.  ZAJPT  also  influenced  the  multi-way  communication  models  of  our  Multi-Media 
Conferencing  (MMC)  and  Scalable  Pmsonal  'Kli^nferencing  iSFT)  projects.  Our  condusions 
include  comments  about  off-site  interoperation,  fiail-safety,  and  security.  Tlie  NeXT  was  also  eval¬ 
uated  as  a  potmitial  digitd  A/V  telecometenoe  platform.  We  recommend  eventual  rqilacmnent  of 
21/UPT  with  a  system  t^gned  for  off-dte  call  capability. 

2.0  Goals 

The  goal  of  ZAPT  was  to  permit  ARPA  to  re^  the  benefits  of  teleconferencing  projects  it  has 
supported,  for  intnnal  use,  as  wdl  as  to  showcase  the  technolo^  ARPA  supports,  using  “off-the- 
shelf”  components  and  software.  ARPA  has  ftinded  various  wide-area  teleconferencing  projects, 
including  fiiose  that  use  die  TWBNdA^SINet  [Q^]  and  DARTnet  netwoddng  testbeds,  as  well 
as  sujqxMting  components  of  other  teleconferencing  projects.  Each  of  diese  projects  has  its  own 
qxdfic  goals,  priiqatily  rdated  to  technology  devdopment  or  servicing  external  users.  In  early 
1991,  when  ZfJfJr  was  devdoped,  the  existing  ARPA  proje^  were  research  only,  and  not 
appropriate  to  support  impromptu  tehxonfermicing,  in  a  “no  white-coats”^  style.  While  commm:- 


1.  TUs  lesearch^ffioasond  by  the  Advanced  ReseaidiPnojectsAgeQcyiiuoughR.Huacbuc8CoDtnict  No. 
DABT63-91-C-0001.  the  views  and  oondorioos  contained  in  ibis  document  are  those  of  the  authors  and  should  not 
be  intEqpieied  as  rnreseming  the  dBBcial  poUdes,  either  expressed  or  implied,  of  the  DqKuunent  of  die  Army,  die 
Ddbnse  Advanced  Research  Picjects  Agency,  or  the  UJS.  Government 

2.  ZAPT  was  originaDycaDed  “ACT- Automated  Ouster  Tfeleconferencing”.  The  name  was  changed  to  distinguid)  it 
from  die  ACTS  profect,  which  involves  satellites. 

3.  “no  whitecoats”  impUes  user-managed  operation.  No  lab  personnel  or  tecfanidaiis  should  be  feqoued. 
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dal  providcfs  of  tdeconferencing  existed*  the  equ4>nient  and  setup  costs  vKxe  prohibitive*  and 
th^  were  designed  for  conference  rbom  use*  rath^  Aan  desktop  teleconfnendng. 

ZAFTs  prima:7  goal  was  high-quality,  low  cost,  multipatty  desktop  tdeconfeiencing  at  ARPA. 
21AFT  uses  existing  software,  to  minimire  delivery  time,  and  also  uses  existing  hardware  at 
ARPA*  specifically  die  NeXT  systems  and  analog  ofSoe  cabling.  Security  was  also  a  goal,  and 
interoffice  analog  wiring  was  deemed  suffidratly  secure. 


3.0  Description 

Here  we  describe  die  ZAPT  system,  vriiich  is  composed  of  a  modified  version  of  BeUcore’s  Tour¬ 
ing  Machine,  widi  bridging  and  switchin|  extensions*  as  well  as  modified  automated  user  clients. 
Tte  discusrion  includes  a  system  oven^w,  (tescripdon  of  the  user  interface,  and  summary  of 
internal  modifications  diat  afect  the  system  behavion 

3.1  System  Overview 

The  Tooting  Machine  is  an  analog  multimedia  teleconferencing  system  based  on  centralized  con¬ 
trol,  develop  at  Bellcote  [At92]  [Ar93].  At  the  time  ZAPT  began,  the  TM  was  due  existing  sys¬ 
tem  that  most  closely  match^  ZAPT  objectives.  Bdlcore  cormidy  uses  the  TM  for 
tdeconferendng  among  offices  within  one  site  and  between  two  sites  SO  miles  apart  Bellcore 
supported  efforts  at  MIT  and  Uiuv.  of  ^i^sconsin  to  port  die  TM  to  odier  computers,  and  was  will¬ 
ing  to  release  its  software  for  ARPA  use. 

TM  contains  two  user  interfaces:  MTS  Qow-level)  and  CRUISER  Otigh-levd),  implemented  in 
XU,  on  Snn-3  derictop  computers,  with  ihdqiradent  analog  audio  and  video  citing.  MTS  was 
chosen  because  it  was  more  portable,  as  we  will  discuss  later.  The  IM  manages  the  analog  con¬ 
nections  nring  switdiing  and  bridging  ^uipment  residual  fixim  prior  testbeds  at  Bdlcore.  The 
ZAPT  system  is  shown  in  Figure  1,  and  its  architecture  is  dominated  by  the  TM  components.  The 
TM  provides  an  analog  local  distribution  systmn,  which  ZAPT  augments  widi  badc-end  connec¬ 
tions  to  odier  conferencing  systems  via  the  Internet 


FIGUKE  L  ZAPT  tjrstem  overview 

In  dm  TM,  emsting  IP  transmissions  (via  Ethernet)  are  used  for  control,  and  an  analog  crossbar 
provides  audio  and  video  switching.  At  Bellcore,  Son-3’s  ate  used  to  control  separate  user-end 
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analog  equqnnent  (camera,  monitor,  microphone,  speaker).  At  ARPA,  die  analog  video  monitor  is 
I»ovided  by  ^  NtiKT  via  the  NeXTDimen^on  board,  using  the  NeXTtv  implication  to  display 
retd-time  hTTSC  video  on  the  color  monitor  (Hgure  2).  At  toth  BeUcoie  and  ARPA.  analog  sig¬ 
nals  are  carried  by  a  (fi^inct  cabling  network,  and  digital  and  analog  interact  only  at  the  crossbar 
switch.  The  bridging  at  ARPA  is  completely  passive  (analog  signal  indqiendeot  mixing  only), 
whereas  BeUcoce^s  is  active  (includes  signal-dependant  mixing  as  well  as  switching). 


FIGURE!.  ZAFT NeXT  components 


User  interface 


The  ZAPT  usa  intnface  has  four  components  -  the  ZAFT  Manager,  MTS,  SMGR,  and  NeXTtv. 
The  ZAPT  Manager  is  a  NeXT-style  application,  which  starts  the  visible  and  undmlying  user  cli¬ 
ent  components,  replacing  Bellcore’s  command-line  startup  script  The  manager  integrates  com¬ 
ponent  mtiation  with  fcuhiie  recovery,  and  controls  the  user  component  processes  via  Unix 
signals  -  one  which  restarts  the  user  components  (SIGJNT),  and  the  other  ^ch  shuts  the  user 
ccmmonents  down  (SIGQUIT).  Hgure  3  shows  the  NeXT  icon  for  this  user  startup  intoface.  Hg- 
ure  3  also  shows  that  interface  opened,  with  its  menu,  and  two  control  buttons  (Restart  and  Quit). 
Hgure  4  shows  the  ’Tnfo”  submenu,  and  the  information  panel  menu  itrai,  and  panel  itself. 


FIGURE  3.  ZAFT  Manager  icon,  main  menu,  and  main  panel  (actual  sbe) 
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FIGURE  4.  ZAFT  InfSBCtnation  pand  (actaal  aize) 


Analog  video  is  displayed  on  die  NeXT  via  NeXltv,  a  demo  qiplicalioii  provufed  with  NeXTDi- 
mension  boards.  A  sample  video  window,  showing  quadrant-split  multiparty  teleconfetencing,  is 
shown  in  Hguie  S.  NeXTtv  conies  up  "ofi”  -  usos  must  manually  “tem  on**  die  tv,  using  the 
‘*powei**  button  in  the  lower  left  ooinec 


IIGURB5.NcsXTtr  vlewof  a  iwdtipwty  teleotwfcraice  (redaeed  Iqr  50%) 


MTS  and  SNK3R  ate  TM  X-windows  user  intnfaces  that  tun  diiecdy  on  the  NeXT,  under  co-Xist 
(a  NeXT  triplication  that  provides  X-windows  compatibility).  MTS  is  a  Bellcoie  IM  client  appli¬ 
cation  for  amfeiendng  control  designed  for  computer  sdentists.  Bellcore*s  Cruiser  clioit, 
designed  for  casual  users,  was  not  used  because  it  leUes  on  X-windows  extensions  not  available 


ZAPTH^K^ 


niuler  co-lQst  Rgofc  6  shows  a  sample  of  die  MTS  user  interfiace  and  SMGR  endpoint  control 
tool,  bodi  of  ti^iidi  are  unchaii^  from  Bel^rB*s  Siin-3  vision,  exc^t  for  the  NeXT>style  wic- 
manager  *iconize”  and  "^close'*  buttons^. 

The  MTS  intetface  provides  call  inidadtm  and  re^nse,  as  well  an  multmle  call  management  A 
user  selects  die  callM  parties  from  a  static  user  Ust  and  initiates  a  calL  Calls  can  be  accepted  or 
refused  by  the  user,  or  SMGR  can  auto-aocept  (di^nssed  below).  Calls  in  progress  can  be  sus- 
praded,  resumed,  or  brought  to  the  fore^und  Qn  the  case  of  multqile  calls  in  progress).  An  indi¬ 
vidual  call  can  tove  its  audio  in,  audio  out  video  in,  or  video  out  individually  activated  or 
deacdvated  on  a  per-nsm:  basis.  A  call  can  also  be  in  **^Ut  screen**  mode,  or  point-to-point  mode. 
Calls  to  more  dum  one  other  party  automatk»lly  initiate  split-screen  mode.  Up  to  3  other  parties 
can  be  part  of  a  sin^  call  (for  a  total  of  4,  including  die  filler).  Only  one  multi-par^  call  can  be 
in  session  at  a  time  in  this  instaUation  of  ZAFT,  aldiough  any  number  of  point-to-point  calls  can 
occur  simultaneously.  In  addition,  individual  users  can  be  added  or  deleted  from  a  current  call,  at 
the  discretion  of  any  cunent  membm*  of  the  calL 

In  addition  to  MTS,  each  station  has  a  control  interface,  called  SMGR,  also  shown  in  Figure  6.  A 
station  is  defined  as  a  set  of  enr^xtints,  shared  among  tte  user  client  processes.  SMGR  is  used  to 
change  the  default  policy  for  session  requests,  from  manual,  to  auto-acc^t,  auto-deny,  and  pass¬ 
through  (not  o%d  fiMrMI^).  It  also  shows  die  status  of  the  endpoints  of  a  station. 


ZAFT  includes  a  number  of  internal  modifications,  which  support  modes  of  operation  beyond  that 
available  at  Bellcore*s  Touring  Machine  installation.  These  include  pasrive  bridgmg,  faitit-detect- 
ing  switching,  automated  usa  client  operation  supporting  cross-coupling,  and  frul-safe  user  and 
syston  component  maintmance. 

1 .  A  bug  in  o>-?Qst  die  *‘ck>se**  button  on  die  NeXT-style  windows  to  quit  die  user  iqiplkation.  oo-^Qst  imple- 

meats  uwm  wnuguics,  where  die  close  means  QUIT,  rather  than  twm  semantics,  where  dose  means  CLOSE. 
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3JJ  BHd^ 

Belkoie  uses  an  (expendve)  active  tiridging  system  as  part  of  their  TM  inaalladon.  Bellcore  pro¬ 
vided  die  TM-side  this  software,  vdiich  was  modified  for  use  with  passive  bridging  equipment 
in  ZAFT.  The  video  bridge  at  both  21APT  and  Bellcore  was  passive,  and  we  configured  an  ii^x- 
pensive  lEAC  Tascam  studio  mixer  to  provide  passive  audio  bridging  in  ZAPT  as  welL  Bridging 
reservation  requests  ate  satisfied  on  a  first-come  first-served  basis. 

Active  bridging  is  signal-dependant  mixing;  in  Bellcore’s  case,  the  mixed  signal  ouqmt  is  a  “loud¬ 
est  2”  ncMCtnalized  summation  of  the  inputs.  In  addition,  Bellcore’s  bridging  ^stem  performs  some 
switching  as  well  Passive  bridging  is  signal-indq)endrat  mixing;  in  ZAFT,  each  output  is  an  “aU 
but  me”  sum  of  the  inputs  (regardless  of  signal  on  those  inputs).  One  advantage  of  ZAFT*s 
^proach  is  its  alnlity  to  correctly  compose  midtiple  bridges,  lb  compare  the  two,  consider  4  sites 
in  conference,  W  and  X  near  bridge  A  and  Y  and  Z  near  bridge  B.  Bridge  A  unites  W,  X,  and  die 
ou^ut  of  B.  Bellcore’s  case,  W  hears  03  X  +  0.25  Y  -f  0^  Z,  so  tte  remote  participants  ate 
not  as  loud.  Li  ZAFT,  W  hears  X  -f  Y  +  Z,  as  it  would  in  a  conferrace  room,  removing  o^y  direct 
feedback.  “All  but  me”  bridging  is  limited  to  small  groups,  because  background  noise  is  added. 

ZAFT  is  the  only  bridging  TM  outside  of  Bellcore  itself.  Bellcore’s  bridge  manager  software 
component  of  the  TM  performs  trunk  reordering  to  undo  some  of  the  switching  done  by  their 
active  bridge.  ZAFT*s  bridging  software  relies  on  the  TM  resource  allocation  mechanism  to  pre¬ 
serve  trunk  order;  an  assumption  that  may  not  be  valid  for  multinode  switching  using  Bellcore’s 
vision  of  resource  managem^t  Bellcore  has  leincorporated  the  2AFT  modifications  into  their 
software,  and  is  examining  its  implications  on  resource  management  in  die  TM. 

3J^  Switching 

The  2^AFr  switching  control  software  is  adiqited  from  code  MIT  rteveloped  for  use  with  their  TM 
installatiooL  21AFT  ^ows  the  command  stream  down  with  fixed  delays  to  prevent  serial  line  over¬ 
run,  and  verifies  all  serial  port  writes  vdth  echo-reads,  resulting  in  more  reliable  operation  and 
fault  attribution.  Diagno^  of  this  problem  was  facilitated  by  Ae  development  of  SoftPanel,  a 
curses-based  (terminal-type  independent  full-scremi  ASCII)  tool  for  control  of  the  switch  using 
an  ASCII  terminal  (Appmidix  Q.  SoftPanel  has  been  given  to  the  crossbar  switch  manufacturer, 
as  well  as  made  available  on  the  Internet  via  anonymous  FTP. 

3JJ  Cross-^oupUng 

ZAP!  can  interconnect  with  Intonet  teleconferencing  via  manual  cross-coupling^  Side-effect 
cross-cotq)ling  uses  an  automated  TM  client  and  other  Internet  teleconteiencing  tools  indqp^i- 
dently.  The  d^gn  is  the  equivalent  of  a  “null  modem”  cable  (Figure  7).  These  connections 
requite  manual  coimect  of  each  side  of  the  conf(»ence,  ie.,  a  ten^zvous  at  a  proxy.  Users  never 
tecdve  calls  initiated  from  die  proxies,  in  this  case.  As  far  as  the  TM  clients  ate  aware,  they  have 
coimected  to  an  office  called  “external”.  As  far  as  the  mrtemal  client  (e.g.,  MMCX^  is  aware,  the 
local  client  has  switched  the  audio  and  video  to  a  different  conference  room. 

Folly  automated  cross-coupling  would  avoid  separate  control  actions  on  the  two  conferencing 
systems.  A  user  on  TM  calling  an  external  user  would  result  in  a  call  to  the  proxy,  and  dm  proxy 
would  complete  the  link  by  initiating  tux  external  call  to  the  external  usee  This  requires  a  connec¬ 
tion  protocol  diat  is  conqiatible  with  both  TM  and  the  extnnal  system  semantics.  We  designed  an 
interoperation  protocol  iror  this  purpose,  which  was  equivalent  to  cucumnavigating  TM  mitirdy, 
and  thus  not  implonented  (Appendix  A).  A  proxy  needs  to  emulate  the  protocol  at  the  user  climt 
level  The  dimit  protocol  for  external  Intranet  teleconfraendng  tools  were  documented  (e.g., 
MMCC  [Sc92a]  [Sc93]),  the  TM  was  not  We  developed  a  pactet  probra  to  determine  the  TM 
protocol  and  developed  an  extension  to  it  for  proxy  operation  (Appraidix  A).  We  also  developed  a 
^tocol  for  communication  between  the  TM  and  MMCC  clients,  equivalent  to  a  2-paity  connec¬ 
tion  protocol  (Appendix  A). 


1.  Automated  cross-coupling  was  considered,  but  deemed  beyond  the  scope  of  tiuspfOfect 
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ZAFT  uses  the  MTS  client,  in  conjunction  with  an  SMGR  client  modified  to  auto-acc^  to  sup¬ 
port  call  management  via  side-effect  cross-coupling.  Side-effect  cross  coupling  is  the  lii^  foim^ 
two  teleconferencing  systems  (»11  a  *^ull-modeffi**  -  die  link  is  a  si^  meet  of  the  call,  not 
due  to  connection  status  crossing  t!ie  link  boundary.  This  supports  only  the  conventional  IM  call 
model,  whoe  only  existing  call  members  can  add  additional  parties  to  a  currmit  call 

ZAFT  also  supports  radio-like  broadcasts,  in  wfakfa  users  join  int^pmidently  via  the  Radio  proxy 
application.  The  Radio  proxy  is  an  application  that  replaces  MTS.  The  Radio  reqionds  to  caU 
requests  to  add  that  user  to  the  current  broadcast  session  .  The  SMGR  client  was  modified  to 
avoid  the  X-windows  interface,  to  permit  automated  operation.  We  used  the  Bubble  trace  program 
(Appendix  C)  to  determine  a  protocol  for  the  Radio  proxy.  The  Radio  proxy  was  not  releas^  in 
ZAFT,  because  the  protocol  was  optimistic  only  (thus  not  fault  tolerant).  Further  detail  of  the 
Radio  inoxy  iq)peats  in  /qipendix  A. 

We  also  attempted  to  augment  the  Radio  proxy  to  perform  both  broadcast  and  point-to-point 
direct  <»lls.  Tlw  proxy  was  to  perform  dual  registration,  as  Radio  and  MTS  clients;  calling  the 
Radio  would  results  in  a  callback  join  to  a  broadcast  session,  calling  the  MTS  proxy  would  result 
in  point-to-point  auto-acoqit  call  operation.  The  Radio  and  MTS  proxy  had  to  be  implemented  in 
a  single  m^ule,  because  they  share  state.  When  the  Radio  had  a  broadcast  sesaon  active,  the 
MTI^  proi^  should  re^XHid  *1)usy”  to  all  requests,  and  vice-versus.  The  dual  client  was  not  com¬ 
pleted,  because  of  the  lack  of  fault  toloance,  as  noted  above. 

3J.4  FaUurt  detection  and  recovery 

ZAFT  augments  the  TM  model  of  system  fiEult-tolerance,  because  AREA  requires  the  privacy  of 
fail-str^  operation.  Failure  of  the  control  ^stem  should  result  in  failure  of  the  audio  and  video 
links;  othoudse,  transmissions  continue  wi^ut  explicit  action.  Individual  components  of  the  TM 
implment  some  ample  fook  tolerance,  but  doe  to  a  lack  of  soft-resets  the  set  of  components  is 
not  tolerant  of  individual  componmit  fiulote.  IM’s  failure  mode  also  kBq)s  a  connection  up 
componmits  fail  (fail-stay),  rather  than  keeping  tiiem  down  (ftul-stop)  as  AREA  requires.  Tte  TM 
ardiitectore  did  not  pomit  a  fail-stop  design,  in  general,  but  a  specific  version  of  fail-stop,  forcing 
entire  system  reboot,  was  posable.  21AFT  al^  supports  self-restart  in  the  event  of  failure. 

We  designed  SafeNet  to  manage  fault  tolerance,  and  incorporated  it  into  the  ZAET  systmn. 
SafeNet  u  a  process  that  monitors  the  compoimnts  of  the  TM,  and  spawns  the  failed  componrats 
in  the  proper  order,  eitho’  at  the  ^tem  or  us^  level  (Figure  8). 


1.  IM  version  2  does  not  have  a  sesskm  join  request 
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The  TM  (XMisists  of  a  core,  composed  of  7  indepradent  coo^nents,  and  user  sites,  each  com¬ 
posed  of  5  components.  TM  core  state  information  is  kept  when  die  core  fails,  but  can’t  be  reset  or 
re^nchronized  once  the  TM  is  running.  IM  core  state  information  needs  to  be  reset  to  some 
known  state,  but  the  TM  us»  climts  aren’t  aware  of  that  state.  As  a  result,  user  clients  can  fail  and 
restart  \^e  the  core  is  running,  but  core  failure  requires  user  clients  restart  the  core  restarts. 

Ideally,  the  core  SafeNet  would  sign^  the  user  SafeNets  to  restart  after  it  rebuilds  the  core.  In  the 
cunrnit  syst^  a  user  attempting  to  initiate  a  call  after  a  core  restart  is  told  he  doesn’t  exist,  and 
most  infer  his  own  restart  action. 


FIGURE  8.  TM  Core  and  user  clients  SafeNet  conflguntioiis 


The  core  system  configuration  in  Figure  8  indicates  that  when  any  system  component  fails,  the 
entire  system  is  restarted.  The  user  configuration  in  Figure  8  indicates  that  the  user  components 
exhibit  a  restart  structure,  Le.,  that  MTS  can  be  restart«l  without  restarting  other  components,  but 
that  STATION  failure  requires  restarting  SMGR  and  MTS.  The  SafeNet  software  is  also  inte¬ 
grated  into  the  ZAPT  Manager  NeXT-style  application. 

3.4  Modification  summary 

The  time-line  of  the  components  of  the  21APT  software  is  shown  in  Figure  9.  We  started  in  mid- 
June  1992  with  Bellcore’s  Touting  Machine  version  2  of  May  1992.  We  ported  that  to  the  NeXT¬ 
Step  operating  syst^  in  June  1992.  MIT’s  switch  module  was  added  in  September.  We  also 
receiv^  a  copy  of  Bellcore’s  bridging  module,  which  was  also  significantly  modified  to  accom¬ 
modate  passive  bridging.  The  final  system  was  completed  in  February  1993.  Otha  components 
were  added  to  augment  the  TM,  which  included  Safi^et  fault  management,  the  NeXT-s^le  uso- 
interface  startiq)  manage',  and  the  auto-accept  SMGR  and  Radio  components. 

BconWvl  «0 


ZAPT4/85 


FIGURE  9.  Touring  Macfaine  source  tree 
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4.0  Accomplishments 

Tbe  ZAPT  project  realized  several  accomplishments  in  its  1-year  charter.  21AFT  provides  interof¬ 
fice  desktop  tdecoitferencing  at  with  a  NeXT-style  application  startup  mterface.  It  pro¬ 

vides  automatic  additions  to  broadcast  confnences,  and  automatic  cross-coupling  to  existing 
Intonet  digital  teleconferencing  tools  ^e.,  rrnidezvous  capability).  ZAPT  has  bwn  used  for  sev¬ 
eral  2h(ernet-wi^  teleconferences  at  ARPA  in  the  past  few  months,  and  has  dmnonstrated  die  util¬ 
ity  of  de^top  tdecor^eiencing  at  ARPA. 

ZAPT  also  provides  fault-tolerance  via  module  restart,  and  inexpensive  passive  brid^g.  What 
we  learned  about  fnilt  tolerance  and  passive  bridging,  as  well  as  about  the  TM  modd  in  general, 
has  been  shared  with  the  research  community.  Ow  crossbar  debug  module  has  been  made  avail¬ 
able  on  the  Internet  via  anonymous  FIT,  and  has  been  given  to  XN  Ibchnologies  (the  switch  man¬ 
ufacturer). 

Rnally,  the  experience  of  developing  and  installing  ZAPT  has  influenced  our  models  of  multime¬ 
dia  tdeconferencing  from  anoth^  viewpoint  We  have  attempted  to  begin  such  a  model,  called 
“M3**  -  the  Multicast  Multipoint  Model  rib92].  Our  model  supports  conference  merging  and  sub¬ 
conferencing,  neither  of  idiich  is  support  in  MMCX^  or  the  Touring  Machine.  It  also  p^mits  co- 
mingling  of  different  data  stream  types,  permitting,  e.g.,  audio  to  go  to  an  oscilloscope  whose 
video  goes  to  a  monitor:  MMCC  and  TM,  as  well  as  some  propos^  lETP  MMUSIC  Working 
Group  mod^  [MM93],  currently  enforce  strict  stream  partitioning  by  type.  In  addition,  we  rec¬ 
ommend  a  dynamic-state  model,  in  wdiich  resources  and  state  have  a  “fi^**  ground  state,  and  aro 
krat  reserved  only  by  continual  reffesh  requests.  This  permits  a  true  fail-stop  system.  The  physi¬ 
cal  crossbar  should  M  part  of  a  logical  switching  ^stem  that  includes  a  logical  crossbar  and  logi¬ 
cal  ii^iut  and  output  gates,  where  sesaon  control  governs  the  logical  crossbar,  and  nsm:  end- 
control  governs  the  gates,  as  noted  in  the  goicral  recommoidations.  These  concepts  are  bdng 
^veloped  to  influence  boA  the  MMUSIC  and  SPT  models  [Sc93]. 

5.0  Conclusions 

We  found  that  desktop  access  to  fiiternet  teleconferencing  is  more  useful  than  interoffice  telecon¬ 
ferencing  at  die  local  site  only.  This  would  permit  informal  collaboration  regardless  of  proximity. 

Video  teleconferencing  has  become  mote  widespread,  due  to  efforts  of  the  IbTK  The 
MBONE  now  teaches  over  500  hosts  world-wide  with  multicast  IP^  [Ca92],  and  casual  broadcast 
conferences  ate  a  daily  oocunence.  This  so-called  ‘TETF-slyle’*  teleconferencing  has  become 
popr^,  using  Sun  SPARCs,  SGI  Indigos,  and  DEC  SOOOs.  Utf  ortunately,  NeXIh  ate  not  among 
th^  support  due  in  part  to  limited  access  to  their  OS  sources  (no  midticast  IP  is  availabl^), 
and  diffmences  in  windowing  systems  (Xll  isn*t  native).  The  Internet  teleconfermcing  tools 
were  not  efficiently  mature  when  ZAPT  began  in  1992,  but  have  become  pervasive  in  the  past 
year.  As  a  result,  ZAPT  Aould  eventually  be  replaced  with  the  evolving  Internet  tools. 

We  also  evaluated  die  NeXT  as  a  general  audio/video  teleconferencing  platform,  in  condderation 
of  suf^XMling  existing  Interne  distal  teleconferencing  tools.  The  hardware  and  operating 
system  were  evaluated  few  IP  multicasting,  continuous  digital  audio,  and  continuous  digim  video 
ca(Nt^ity.  Bodi  tolerating  system  and  hi^ware  were  found  to  be  lacking,  at  this  time.  There  are 
t^ier  competing,  woprietary  digital  teleconferencing  systems  for  the  NeXT  hardu^ue.  Most  use 
die  SC^I  Digital  eyes  video  digitization  hardware,  and  provide  conferencing  only  over  a  local 
network.  The  systems  use  Ediei^  broadcast,  rather  than  IP  multicast,  for  data  distribution.  One 
^tem,  called  *X^llaboratB**  (from  Ttident  Data  Systems,  as  a  commercial  product),  provides 
auefio  and  video,  althou^  wife  high  latency  (2  seconds).  Another,  called  “R^o**  (firom  CWI, 
ffeeware),  provides  only  audio.  None  of  the  systems  is  ctqiable  of  wide-area  teleconferencing. 


1.  TUsisatiieasiBeofbo6tsaooe8sinstbeSaiiiinerl993IEIP. 

2.  could  not  add  IP  mulikast  to  die  NeXX  due  to  lack  of  source  code/toxd  access  to  tbe  operating  system. 
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either  spanning  moltiple  LANs  or  over  laige  latencies,  and  both  use  audio  and  video  formats  not 
compatible  widi  Internet  video  teleconferencing. 

Digital  packet  audio  and  video  on  die  NeXT  were  also  examined  as  part  of  this  effort  Hie  Inter¬ 
net  currently  uses  a  suite  of  components  that  provide  loose-style  tele^nferencing.  Ihe  results  of 
diis  evaluation  are  described  in  ^pendix  B.  Also,  using  the  Intranet  for  regular  teleconferencing 
requires  resource  resravation.  Tl^  are  no  automatic  tools  for  reservation  of  DARTnet  at  diis 
time,  although  some  are  pending  implementation.  DARTnet  currently  has  a  manual  mechanism 
for  resravation  of  the  switching  nodes  for  protocol  experiments,  but  dib  does  not  include  die  end- 
^tran  equipmrait  This  sravice  should  be  included  in  any  future  plans  to  provirfe  operational  tele¬ 
conferencing. 

5.1  Reoommraidatitnis 

Based  on  our  evaluation  of  the  ZAPT  effort,  we  recommend  that  the  Touring  Machine  componrait 
be  replaced  with  a  teleconfiraencing  Systran  that  supports  multiple  domains  a  priori.  Ihe  obvious 
solution  is  to  move  towards  existing  Internet  tel^nferendng  tools,  such  as  MMCX!  and  sd. 
These  run  on  a  number  of  existing  platforms,  but  unfortunately  the  Ne^  is  not  among  these.  The 
simplest  solution  requires  leplac^ent  of  die  NeXT  Cubes  with  a  platform  supported  by  the  hiter- 
net  teleconfraraicing  community.  If  NeXTh  must  be  supported,  a  separate  effort  would  be  required 
to  port  some  of  the  call  management  tools  (e.g.,  USC/KTs  MMCX^,  LBUs  sd)  to  the  NeXT,  and  to 
au^ent  them  to  accommodate  shared  control  of  network  resources,  such  as  switches,  analog-to- 
digital  converters,  etc. 
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7.0  Appendix  A:  automated  client  protocols 

The  following  is  a  descnption  of  the  automated  client  protocols  developed  to  extmid  the  TM  to 
handle  automated  cross-coupling  with  external  teleconfeiencing  systnns.  It  was  not  fully  imple¬ 
mented,  because  its  compleidty  began  to  rival  that  of  the  TM  its^ 

The  TM  is  described  by  a  set  of  operations  -  initialization,  database  access,  call  initiation  (outgo¬ 
ing),  and  call  indication  (incoming,  each  of  which  needs  to  be  modified  to  accommodate  proxies. 
A  proxy  needs  to  register  each  client  on  whose  behalf  it  act^  in  addition  to  itself,  via  registerCU- 
ent  (Rgure  10).  Odb  to  tl^se  dirats  need  to  be  translated  into  a  call  to  the  proxy;  a  “Bobble”  is 
inse^  between  xisec  climts  and  the  central  system,  to  effect  diese  translations  (Figure  11). 
Nameserver  replies  are  filtoed  by  the  Bubble,  to  hide  proxies  from  user  clients  (Figure  11). 


watelafCflent  BiS.  anuomonm 
t*dl»tKOIIantMan.anuomormaf 
wgfatifCawit  proxy 


Q  Proxy  ^ 


FIGORE  M.  Proxy  registen  for  each  user  H  represents,  plus  ttsdfl 


FIGURE  11.  The  IM  general  orgunixutioa,  witfa  Bubble  for  proxy  trandations,  with  nameserver  filtering. 

(insider  calls  from  the  TM  to  the  remote  client  (proj^  call  requests),  and  calls  from  fiie  remote 
client  to  a  user  inside  die  TM  (proxy  call  indications).  TM  users  register  via  registerCUent  (Loi- 
tial).  A  TM  call  starts  widi  a  user  sessUmCreate^  ai^owledged  by  a  sessior^equestReceived 
message  (Create).  The  TM  core  sends  sessionActionRequest  to  all  monbets,  and  collects  a  ses- 
oonAcdonAccept,  sessionAcdonDemed  or  timeout  for  each  (Reply).  Eventually,  a  sesdonActum- 
Commit  or  sesdonActianAbort  is  smt  to  each  membn  including  the  initiator),  indicating  die 
result  of  die  call  (Accent).  This  protocol  is  denoted  in  Hgure  12. 

TM  User  TM  Core  TM  User 


Initial 

Create 

Reply 

Accept 

■1.1: 

1 - J 

FIGURE  12.  ConTentfonal  TM  sessioD  cstabUslunent  protocoL 
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When  a  IM  user  petforms  a  call  request  in  the  augmented  protocol,  remote  users  in  the  initial  ses- 
sUmCreate  are  checked  in  the  nameserver  by  die  Bubbl^  and  replaced  by  the  indicated  proxy 
(Create),  whidi  has  already  registered  all  accessible  users  p  priori  (Mtial).  The  request  is  for¬ 
warded  to  the  central  system,  wUch  srads  it  to  the  proxy  (R^ply).  The  proxy  executes  an  external 
protocol  to  coimect  to  die  remote  proxy,  and  accqpts  or  denies  iba  request  as  indicated.  Tte  rqily 
from  the  proxy  is  translated  in  the  Bubble  at  the  TM  user;  who  receives  the  final  reply  (Reply). 
See  Figure  13  fm*  details. 


Call  indications  in  the  augmented  protocol  originale  at  the  remote  pror^,  by  a  connection  request 
The  proxy  regisleis  the  dients  of  die  incoming  call,  and  sends  a  sessionCreate  to  the  central  TM 
(Cr^).  The  rest  of  the  protocol  proceeds  inside  tte  TM  side  as  before,  and  finally  an  admowl- 
edgment  is  sent  to  the  rmote  proxy,  as  in  Figure  14  (Accept).  Other  actions  occur  as  in  the  proxy- 
extensions  for  the  call  request  protocol,  as  in  Figure  13. 


TMUser(lbm)  Babble  TMCore  Proxy  Remote  Proxy 


Create 

Accept 


FIGURE  !<<.  Proxy  TM  call  indiaitioo  «eask>n  r^»blkhtnent  protocoL 


There  is  a  sqiarate  protocol  between  the  local  and  remote  proxies,  repres^ting  two-party  connec¬ 
tion  establi^toent  The  state  machine  and  events  are  show  in  Figure  15. 
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xCR:xCO 


FIGURE  15.  n:vxy>prQxy  connection  protocol 

A  word  about  notation  in  these  two  figures.  There  are  S  types  of  messages  -  connect  request  {CR), 
connect  accept  (CA),  connect  deny  (CD),  disconnect  request  {DR),  and  disconnect  accept  (DA). 
Prefixes  indicate  the  source  or  sink  of  tiie  message:  U  inrficates  usor  messages,  X  denotes  external 
(remote  party).  For  example,  a  user  cormection  request  is  UCR,  In  tiie  state  diagram,  to  indicates  a 
timeout,  *****  is  no  message,  and  errors  are  not  ^own.  The  states  are  named  connected  {CON),  dis- 
cotmected  (PlS),  user  connecting  (JUCON),  us»  disconnecting  (UDIS),  extonal  connecting 
(XCON),  estiemal  disconnecting  (XDIS). 

We  have  described  the  differences  between  the  TM  and  automated  client  protocol,  in  all  other 
re^)ects  shoitid  be  equivalent  In  particular;  the  timeout  and  &ult  tolerant  behavior  is  not 
affected  by  tiiese  extensions,  but  would  need  to  be  implemented  to  provide  an  environmoit  in 
wfa^  to  effect  medications. 

7,0 J  Broadcast  eUent protocol 

We  wanted  to  add  **radio’*  service  by  extending  the  TM  protocoL  An  automated  TM  proxy  can’t 
broadcast  Idiiy  users  can  auto-connect  but  only  one  session  can  be  active  (and  choice  is  under 
proxy  control).  C^reiding  a  session  for  each  user  receiving  a  broadcast  is  inefficient 

TM  provides  a  broadcast  mode,  in  which  a  single  source  is  reedved  by  all  users,  using  a  ‘hus- 
sing’^ciqMtbility  in  tiie  sunalog  switch,  la  TM  version  2,  users  can’t  join  an  existing  session;  ti?ey 
must  be  "addetT  by  an  existing  member 

We  modified  tiie  TM  operation  by  creating  a  Rsulio  client  All  call  requests  are  (teitied  by  Radio; 
such  requests  are  assui^  to  be  a  request  to  join  tiie  broadcast  (Hgure  16).  The  Radio  t^  adds 
the  caw  to  its  brcMidcast  sessioit  R»]io  creates  the  sesdon  when  the  first  user  joins,  and  adds 
nsns  thneaftei;  It  teats  down  ^  session  wlwn  the  last  user  leaves,  releasing  the  proxy  resources. 
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The  Radio  was  designed  to  be  cooperative  with  a  Remote  proxy  clioat  Ihe  Remote  client  imple¬ 
mented  the  automat^  proxy  protocol  Bodi  w^  part  of  a  single  module,  so  shared  state  could 
permit  either  to  acquire  the  external  analog  connection. 


Figure  16  shows  a  simplified  Radio  protocol  Each  transition  is  labelled  with  received  message  / 
internal  action  /  output  message.  An  astnisk  C****)  indicates  no  action  or  message,  and  to  indicates 
a  timeout  The  ‘^idc”  shown  is  to  use  call  requests  as  implicit  join  requests.  The  states  show  are 
umegistBied,  off  (wai^  for  requests),  going  o^  going  off,  and  on  (currently  broadcasting).  The 
protocol  shown  is  optimistic,  b^use  an  optimistic  client  protocol  was  trawable.  A  pessimistic 
protocol,  witii  failure  recovery,  was  not  developed  because  of  insufiScient  information  on  the  TM 
client  protocol 

We  attempted  to  develop  a  more  detailed  Radio  protocol  to  better  model  tiie  state  transitions  nd 
eventually  provide  fault  tolerance.  Li  Figtro  16,  ON  goes  to  GOING  ON  with  a  user  call  request, 
n^di  is  drnued,  and  a  broadcast  call  initiation.  GO^G  ON  should  go  to  anotiier  separate  state 
when  REQUEST  MB  is  received,  Le.,  udien  the  TM  core  asks  the  climit  to  join  Ae  session  it  ini¬ 
tiates. 

Further  detail  involves  the  fault  recovery;  a  partial  elaboration  of  this  state  diagram  appears  in 
Hgure  17.  This  includes  refining  the  paA  of  uansition  from  OFF  to  ON  to  have  2  intmmediate 
steps;  fins  is  inferred  from  tiie  protocol  messages  observed  with  the  Bubble  tracer.  We  would  pre¬ 
fer  to  have  build  tins  diagram  from  a  TM  spet^cation  of  the  protocol  but  none  is  documented  at 
thistime. 

At  tins  point  we  can  see  the  flaw  in  the  general  TM  protocol  that  prohibits  fault  tolerance  in  the 
gmieial  case.  AlAough  we  may  be  able  to  determine  **aboiir  or  timeout  transitions  for  all  other 
states,  the  ON  state  has  no  timeout  possible.  The  TM  assumes  fail-stop  operation  which  continues 
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a  can,  and  state  marhinftB  don’t  interact  while  ON.  A  &ult  tolerant  protocol  requir^  the  ON  state 
to  have  a  timeout,  Le.,  to  have  a  ’’refiesh  connection”  message  to  maintain  state.  This  kind  of  peri¬ 
odic  state  transition  is  well  known  in  existing  transpoit  protocols  (Delta-t,  etc.). 


FIGURE  17.  Man  detailed  Radio  cBent  atate  diagram  (not  oonyd^  and  not  Implemented) 
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8.0  APPENDIX  B:  VAT/ NV  port  results 

The  ZAFT  system  is  a  distal  control  system  for  analog  audio  and  video  signals,  but  Internet  tele¬ 
conference  corrmtly  uses  distal  audio  and  video.  Here  we  summarize  our  attempts  to  port  two 
popular  digital  Ihteroet  teteconfeiencing  tools.  ‘Vaf ’  for  audio,  and  *‘nv”  for  video,  to  tte 
Cube.  Tbe  vat  audio  tool  port  was  unsuccessful,  for  reasons  that  are  still  not  well  understood.  The 
nv  video  tool  port  was  successful,  although  it  exhibited  very  poor  performance,  and  worked  in 
leceive-only  mode. 

8.1  *^ar*p(nrt  results 

We  had  offered  to  port  **var,  the  pervasive  MBone  audio  teleconfermunng  application  developed 
at  LBL  by  V.  Jacobson  [Ja92],  to  the  Neicr  Cnbe^,  but  have  not  been  able  to  obtain  sources  for 
the  past  year.  Potting  would  have  been  complicated  by  vat’s  use  of  C++  (NeXT  supports  Objec¬ 
tive  Q,  and  a  window  sj^tem  padoge  called  ^Interviews”  (which  is  not  supported  on  tiie  Ne]^. 
We  aim  considered  pcxting  ’iievof’,  H.  Schulzrinne’s  vat-compatible  i^pUcation  (at  AT&T  Bell 
Labs  [Sc92b]),  but  were  unsuccessful  at  this  time,  due  to  incomplete  information  on  NeXT  sound 
drivers.  Nevot,  as  vat,  and  most  other  .qmilar  digi^  audio  applications,  uses  a  ’Vdev/audio”  model 
of  sound  access.  Packets  of  audio  are  read  and  written,  and  “ioctl’s”  permit  control  of  the  audio 
device. 

The  NeXT  treats  sound  diffidently.  The  NeXT  plays  and  records  sounds  via  system  calls,  which 
queue  sound  packets,  and  play  th^  via  DMA  tranters  through  the  DSP  chip.  Unfortunately,  we 
^ve  not  been  able  to  accomplidi  even  trivial  bidirectional  continuous  digital  audio,  and  unidirec¬ 
tional  audio  has  worked  oiuy  with  significant  (1  second)  latency.  Use  of  NeXT  hardware  for 
sound  would  require  proprietaty  information  on  the  sound  systmn,  which  we  could  not  obtain 

We  have  been  able  to  modify  (ZWTs  ’*Radio”  program  (not  related  to  the  TM  implication  we 
developed,  also  called  Radio).  The  modified  program  receives  vat-style  packets,  and  plays  them  as 
they  arrive.  However,  even  on  local  networks  with  continuous  packet  transmission,  playout  is  spo¬ 
radic.  We  have  not  b^  able  to  correct  the  playout,  and  expect  that  correction  would  not  be  possi¬ 
ble  widiout  proprietaty  information  on  the  NeXT  sound  system. 

Note  that  the  situation  is  not  he4>ed  by  a  move  to  NeXTStep  486.  The  486  system  has  no  sound 
hardware  compatibitity  defirution.  The  sound  interface  continues  to  be  via  the  OS  call  interface, 
rather  than  via  a  device  emulation  (/dev/audio).  The  NeXT  has  an  undocumented  /dev/sound. 

8.2  *^v*’ port  results 

We  have  also  potted  the  network  video  program  *1nv”,  by  R.  Frederick  of  Jfetox  PARC  {Fr92],  to 
the  NeXT.  This  port  was  mme  snccessM  than  the  audio  port,  and  is  usable,  although  very  dug- 
gish.  It  required  potting  TCL  (command  language  toolbox)  and  TK  (XU  window  toolbox)  to  the 
NeXT  under  co-Xist  The  resultirig  program  works,  provided  the  IP  multicast  video  is  shunted  to 
the  NeXT  by  H.  Schulztiruie’s  FTP  *hiinoi^  to  convert  it  to  a  unicast  IP  streaniL  The  sluggirifness 
is  due  to  the  use  of  co-Xist  for  the  windowing.  Sample  windows  appear  in  Hgures  18  and  19. 

The  main  window  does  not  di^lay  the  **send  video”  options,  because  we  were  not  able  to  port 
them  to  the  NeXT.  The  NeXT  hardware  uses  several  different  realtime  video  di^tization  boanls; 
ours  use  tiie  NeXTDimension  board.  NeXT  does  not  support  the  board,  and  the  dXbrt  required  to 
perform  the  port  would  be  latipe,  and  unwarranted  wiAout  distal  audio  capabili^,  so  was  not 
attempted.  Another  system.  Digital  Eyes,  provides  video  digitization  over  SCSI  intocface,  and 
otiiets  are  considering  its  use  for  digi^  ^econferencing.  Tlw  color  displayed  is  ^ghtly  green- 
dcBwed,  and  apparentiy  reflects  diffidences  in  co-Xist’s  8-bit  pseudocolor  map  vs.  Sun’s. 


1.  vofcarreodynins  00  l^C8,S(38,SiBiSPARCs,HPs,  and  1386  BSDs  only. 
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FIGURE  18.  nr  maiii  wbidow  (witli  ndniature  rtal-tiiiie  video  *^aiiiplO 


FIGURE  19.  Dbphy  of  real-time  video  in  a  separate  vrindow  (nv  featore) 
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9.0  APPENDIX  C:  other  tools 

We  develc^ed  two  pdmaiy  debugging  tools  f(»’  die  ZAFT  project:  bubble  and  SoftPaneL  Bubble 
ats  between  TM  components,  and  shows  the  packet  traffic  tetween  diem.  SoftPand  permits  semi- 
intelligent  control  of  the  AutbPatch  analog  crossbar  switch,  and  permits  readout  of  the  switch 
state. 


9.1  Bubble  traoor 

Bubble  is  a  TM  packet  tracer,  and  was  intraded  to  eventually  evolve  into  the  “bubble”  that  trans¬ 
lated  proxy  operation  as  de^bed  in  Section  33.3  and  Appendix  A.  Bubble  prints  out  packets 
with  a  “v”  prefix  indicating  the  padoet  is  descending  to  the  TM  core,  and  a  prefix  indicating  a 
padcet  is  ascending  out  of  the  TM  cote  to  the  user  application.  It  also  indicates  ffie  paclmt  payload 
length,  and  attempts  to  print  the  packet  payload  as  ASCII  test  Hgure  20  shows  sample  ou^ut  of 
the  Bubble  when  connected  t  the  Radio  user  client 

v:  61.‘(«ncipoin(Map  3 1637720150  iBanMoT^niO 

58:(andpoitilM«pAoc»plt<l  3  *lM>ndto3i4T3;«1*  ItlnidttMTSr) 

v:  87:(aM«ionAelonO«4Ml8166677OS‘lK3:iytTS»10ri6377201S0rAutoH«IUMbyZRAOK>-wflcUlbaclO 

^  1ia(aM*)nActeriAboft  S15SS7706  ‘lMtMTS:s1<r  ‘teabado'JytTST  ‘iMtmdbiMTS:  Auto-rehiM  by  ZRAOiO  •  wU  aril  badO 

FIGURE  20.  Bobble  tracer  output 

93  SoftPanel  crossbar  controller 

SoftPanel  is  a  software  controller  for  the  AutoPatch  analog  crossbar  switch.  It  communicates  via 
the  serial  port  (ttya)  to  the  switch,  and  ^d  control  and  read  status  information.  Ihe  ASCII-termi¬ 
nal  di^lay,  shown  in  Hgure  21,  indicates  the  state  of  the  video  and  audio  crossbar  components 
(video  is  surtounded  by  “v”,  audio  by  “a”).  Commands  sent  are  shown  in  reverse  video;  com¬ 
mands  vmfied  are  shown  in  regular  video.  It  verifies  the  resetting  of  the  switch,  either  via  soft¬ 
ware  reset  (X-boot),  or  powo'-cycle  (Zap)*  It  also  provides  for  smiding  commands,  both  simple 
(Conn,  Dis^nn),  and  aggregate  (Teleconf^  Partcl^  Fullclear).  It  can  read  the  switch  status 
(Read),  and  update  the  display  (Ui^te)  indepradently.  This  software  has  bera  made  available  to 
MTT  and  XN  Tbchnologies,  the  switch  manufacture: 


t^date.  Read,  Conn,  Disconn,  Telconf, 

Partclr,  Fullclr,  X-boot,  Zap,  Quit: 

000000000111  000000000111 
123456789012  123456789012 
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FIGURE  21.  SoCtPand  sct«cti 
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